This is the second article in the short series of articles meant for copilots - Making challenge specifications better qualitatively. If you haven’t read the first article Making Challenge Specifications Better Qualitatively: Overall Objectives, please do so before reading this.
The goal of this series and this article is to ensure that the best practices in writing quality specifications are adopted consistently and widely, and all the copilots are on the same page in terms of the parameters they should ideally look to optimise.
Respecting Competitors’ Time and Effort – In the previous article we briefly explored the three high-level outcomes that high-quality specifications help achieve:
-Increasing Overall Community Engagement
-Inducing better winning submissions
-Improving members’ experience and better utilising their time
Getting better winning submissions and improving average submission are relatively straightforward objectives, hence, much of the discussion in this article is around making participating members’ experience better.
In an effort to make a member’s experience better and keep them from having to waste time unnecessarily, a well-crafted specification should have the following qualities:
1. The specification should be as simple and concise as possible - An effort should be made to make the specification as simple and concise as possible. In other words, a specification should not be unnecessarily verbose and complicated. This is particularly important to consider, given that probably a majority of members are not native English speakers, and English reading comprehension itself might be one of their biggest roadblocks for them. So, in an effort to ensure that English comprehension skills don’t become a big factor in being a good Topcoder member, the specification should be kept as simple and concise as possible.
This also includes use of proper formatting, using lists, and ensuring that the line spacing etc are appropriate, such that the text doesn’t look too daunting to someone who’s not particularly proficient in English reading comprehension.
2. Minimise the need for unnecessary clarifications in the forum – Although members should always be encouraged to ask questions in the forum, an effort should be made by the copilots from the outset to try and write the specification such that there is very less room for confusion, and that a large majority of all possible queries that a member can think of are already anticipated by the copilot and answered directly in the specification.
Of course, not all queries can be anticipated beforehand, but a large majority of them can be in most cases, if proper attention is given to ensure that the specification is structured well from the point of view of a member who is completely new to the project.
Many a times it’s seen that the specification doesn’t contain clarification about something important, and the members end up having to engage in lengthy discussions with the copilot in the forum midway in the challenge. This is extremely inefficient and puts on an extra cognitive load on all the participants to keep tracking the forums for information that should have been readily available to them from the get-go.
3. All communications from the copilot should be ‘transmitter oriented’ - Continuing on the point discussed above, in order to ensure that the copilots do the heavy lifting of ensuring that most things are clear from the beginning, the copilot should adopt the responsibility of making their communications transmitter-oriented (term popularised by Malcom Gladwell in the context of cultural difference is communication orientation). This basically means that the sender of the information (the copilot in this case), needs to take the responsibility of ensuring that everything has been communicated correctly, and that it’s not the receiver’s responsibility to hunt for details that should’ve been made available to them via the specification.
4. If required, specs should be updated during the challenge – If the copilot notices that something is not clear enough from the questions being asked in the forum, they should update the specification in addition to answering queries in the forum.
Furthermore, upon updating the specification they should report the update to the existing registered competitors via a forum thread titled “Challenge Specification updated” to report the specification update, so that challenge competitors who have already read the specification can revisit and read the updated version.
Updating the specification (and not just answering in the forum) ensures that new registrants as well as members already registered, have read the updated specification in case of an update. At times for members joining late, it becomes a quite a tough ask to understand the exact correct requirements, if there has been a lot of discussions and clarifications in the forum, particularly if some information has been provided in the forum that directly conflicts with the information provided originally in the specification. All of this can be avoided, if the specs are kept up the date during the entire challenge, and all updates made to the specs by the copilot are also reported in the forum and vice-versa.
5. Buzzwords and unnecessary abbreviations/acronyms should be avoided – As a general rule of thumb, usage of acronyms, abbreviations, and buzzwords that aren’t very common in everyday English language should be avoided. It’s entirely possible that a buzzword could scare away new members from even attempting a challenge.
6. The specification should start with the big-picture project context and end with the challenge’s nitty-gritty details – As an additional effort to ensure that the competitor is fully aware of everything related to the challenge as well the project, the level of abstraction should decrease gradually. The specification’s abstraction should ideally decrease with each section. As a rule of thumb, the specification should start with basic introduction to all the context related to the project, then move onto the high-level details of the challenge, and finally and gradually lead into the individual details of the challenge. Some recommendations on how to structure the specification has been provided in the next article of the series.
7. In general, specification should be crafted from the point of view of a member who is entirely unaware of the project context - At times we forget the obvious - that although we as copilots might be entirely acquainted with the project and its big-picture, a new participant might not be aware of anything at all. So, we should plan our first contact with the participant with relative care. A simple hack to ensure that the challenge specification is easy to understand, copilots could try to plan the specification by thinking about the how would a new member best understand the problem in case he/she was totally unaware of the problem or the project.
8.Offloading of large amounts of text to the members should be avoided – It should be ensured that almost raw communication from the client should not be directly offloaded to the participating members. The copilots are advised to read and understand the requirements from the client communications well, before beginning the composition of the specs, and write everything in a concise manner in their own words. The “offload large amounts of almost raw text to the members, and let them hunt for the details” situation should be avoided. The specification should ideally only contain relevant text, and nothing extraneous that can confuse the reader unnecessarily.
9. Breaking of spec reader’s flow should be avoided (especially forum resources) – The specification should ideally be composed such that a member can read everything without having to pause reading and go look for some resource. Basically, it should be as self-contained as possible.
A common reason why sometimes a reader might have to leave the page and look for some resource is if a particular challenge resource has been provided in the forum, but no link to that forum thread has been provided. This should be avoided. If some resources need to be shared via the forum, then the links to those forum threads should be provided in the specs as well. A competitor should not have to hunt through the forum to find the matching resource. They should be able to arrive at the exact thread directly from the specification.
These are some of the ways that can potentially improve the overall challenge experience. The Challenge Operations Team is looking forward to finding more areas of improvement in the coming weeks and months. Having gone through the specifics here, in the final article of this mini-series we’ll discuss what the basic layout of a well-crafted challenge specification should look like. See you there!
Scroll down to see the next article in this series.